Control build.sh and .gitignore #1526
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds control of the build.sh and .gitignore files over to `octo`. When it runs, it will generate those files. The build.sh script comes from a template file which is static at the moment. This could be modified to be a go template or something more flexible if necessary in the future. The .gitignore file is generated from a list of strings. For now, this ends up being static, but we could add in logic to generate the list dynamically if needed in the future. Signed-off-by: Daniel Mikusa <[email protected]>
dmikusa
added
type:enhancement
This prevents the tool from adding the script to repos that don't need it. If a repo needs it, it will already have the file. For new repos, you'll need to touch the file first or copy it from another repo. Signed-off-by: Daniel Mikusa <[email protected]>
Signed-off-by: Daniel Mikusa <[email protected]>
Some buildpacks also need to build helpers, like JVM provider buildpacks. The helper needs to be configured in pipeline-descriptor.yml. This commit adds a new `helpers` section where you can define the helpers to be created. The helpers map has the key of the file into which the helper is compiled and the value of which is the module to compile. For example: ``` helpers: "bin/helper": "github.com/paketo-buildpacks/libjvm/cmd/helper" ``` Will result in two lines being added to the build script: ``` GOOS="linux" go build -ldflags='-s -w' -o "bin/helper" "github.com/paketo-buildpacks/libjvm/cmd/helper" GOOS="linux" GOARCH="arm64" go build -ldflags='-s -w' -o "bin/helper" "github.com/paketo-buildpacks/libjvm/cmd/helper":w ``` If you need to reference the module for the current buildpack, you can use the literal `$GOMOD` which is present when the build script runs. For example `"bin/helper": "$GOMOD/cmd/helper"` would build `cmd/helper` from the present module. Signed-off-by: Daniel Mikusa <[email protected]>
|
Thanks @dmikusa for providing a way to automate those changes. Does For example, I've already encountered 4 projects that not only have main/detect/build BUT also have
|
|
Thanks, I hit some similar issues. I have a change to account for this but am doing some more testing with it. Will update soon. |
Signed-off-by: Daniel Mikusa <[email protected]>
|
Ok, I think this is ready now. What I added is a Ex: build cmd/helper from the current buildpack Ex: build cmd/helper from libjvm Then you end up with a structure like: |
|
When we release this, we need to be careful. We can't auto-merge all the PRs because some of the buildpacks will need updates to pipeline-descriptor.yml (for helpers to be added). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds control of the build.sh and .gitignore files over to
octo. When it runs, it will generate those files. The build.sh script comes from a template file which is static at the moment. This could be modified to be a go template or something more flexible if necessary in the future. The .gitignore file is generated from a list of strings. For now, this ends up being static, but we could add in logic to generate the list dynamically if needed in the future.Use Cases
Automatically update the build.sh and .gitignore files, which are basically the same across all the repos. This helps make changes to the resources easier to apply.
Resolves #1100
The only caveat to this change is that we'll need to be very careful on the first run though. This change assumes that the build.sh file is the same for all managed buildpacks. I think that's true, but the first time we'll want to merge all the PRs manually and review carefully to make sure that we're not overwriting anything important.
Checklist