Skip to content

Conversation

@javierdelapuente
Copy link
Contributor

@javierdelapuente javierdelapuente commented Jul 8, 2024

  • Have you signed the CLA?

This PR implements the spec ISD153, "12-Factor Go Support" for rockcraft.

For that, a new init profile called "go-framework" and a new go extension, called "go-framework" are needed. These additions are similar to the flask and django init profiles and extensions, with several differences. Some of the main differences are:

  • Preference for base bare.
  • No dependency on gunicorn. Go generates binaries that are directly executable.
  • By default only one binary is installed (by convention the one with the project name). Including other binaries in the rock will require to change the rockcraft.yaml file.
  • No statsd.

Also, new platforms are added to django, flask extension, so they are the same as in Go.

@javierdelapuente javierdelapuente force-pushed the go-extension branch 4 times, most recently from f771a15 to 7478c81 Compare August 12, 2024 08:30
@javierdelapuente javierdelapuente changed the title WIP go-extension go init profile and go-extension Aug 12, 2024
@javierdelapuente javierdelapuente changed the title go init profile and go-extension Add go init profile and go-extension Aug 12, 2024
@javierdelapuente javierdelapuente force-pushed the go-extension branch 2 times, most recently from 5dafbc1 to 136e881 Compare August 13, 2024 13:16
@javierdelapuente javierdelapuente marked this pull request as ready for review August 14, 2024 13:14
@cjdcordeiro
Copy link
Contributor

@rebornplusplus could be nice for you to have a look at this PR, as it might be one of the future use cases for the user research activities

@javierdelapuente
Copy link
Contributor Author

Hi @tigarmo, can you have a look at this PR?. Thank you!

Copy link
Collaborator

@tigarmo tigarmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

container registries out there.
platforms: # the platforms this rock should be built on and run on
amd64:
arm64:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of curiosity how were these platforms chosen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put all of them in the charmcraft PR for go, and I was suggested to remove armhf and riscv64, as they are not supported by the juju snap.

]
return user_stage

def _get_nested(self, obj: dict, path: str) -> dict:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

two comments here:

  1. I believe dots are valid in part names, so this is fragile. How about changing it to a list of names instead? E.g. the signature could be def _get_nested(self, obj, *parts: str)
  2. This says it returns dict but build-snaps is a list. Seems like this should return Any

Copy link
Contributor Author

@javierdelapuente javierdelapuente Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to be a list instead of a string so dots could be used in part names.

I changed to not get build-snaps directly, as it can be a list as you mentioned, and instead get the object. Otherwise I would need to complicate the _get_nested function to check for the type (and as it is a very simple helper, I preferred not to handle all cases unless more needs arise).

javierdelapuente and others added 7 commits August 26, 2024 15:34
apply suggested fix to docs

Co-authored-by: Tiago Nobrega <tiago.nobrega@canonical.com>
Co-authored-by: Tiago Nobrega <tiago.nobrega@canonical.com>
Co-authored-by: Tiago Nobrega <tiago.nobrega@canonical.com>
@override
def get_supported_bases() -> Tuple[str, ...]:
"""Return supported bases."""
return "bare", "ubuntu@22.04", "ubuntu:22.04", "ubuntu@24.04"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove 22.04 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

Copy link
Collaborator

@tigarmo tigarmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! thanks

@tigarmo tigarmo requested a review from a team August 27, 2024 11:21
@javierdelapuente
Copy link
Contributor Author

Commented all bases except amd64 as discussed.

Copy link
Collaborator

@lengau lengau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, with some minor naming suggestions

Co-authored-by: Alex Lowe <alex.lowe@canonical.com>
@tigarmo tigarmo merged commit 136c0a7 into canonical:main Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants