GitHub-release resource always emits the latest version. I want to get a specific tag with the version specified in a file.
Below did not fetch the version - github-release - pinned version tag: path/to/the/file/with/version not found
- get: github-release
version:
tag: path/to/the/file/with/version
params:
include_source_zip: true
I was able to get the older version by hardcoding the version
- get: github-release
version: { tag : 'v1.0.0' }
params:
include_source_zip: true
and fly check-resource -r pipeline/github-release-resource --from tag:v1.0.0
This is a concourse configuration.
Basically, as stated here, you can't really change this on runtime unless you reset the pipeline:
Pinning through the pipeline config is useful for a more permanent pinned state. If a resource is pinned through the pipeline config, it cannot be modified through the web UI and can only be changed through modifiying and resetting the pipeline config.
Also, the command fly check-resource ... is useful in order to verify the version actually exists.
Related
I want to use pulumi in my CI and do commands like this:
export DATABASE_PASSWORD=$(pulumi config get dbPassword)
but how to I stop this from printing into it:
warning: A new version of Pulumi is available. To upgrade from version '2.12.1' to '2.13.0', visit https://pulumi.com/docs/reference/install/ for manual instructions and release notes.
It's possible to skip the update check by setting the PULUMI_SKIP_UPDATE_CHECK environment variable to a truthy value. See also: https://www.pulumi.com/docs/reference/cli/environment-variables/
Here's what I'm trying to achieve:
I have a project with a build job for a binary release. The binary takes a while to cross-compile for each platform, so I only want to release build to be done when a release is tagged, but I want the local-native version to build and tests to run for each checked-in version.
Based on the flight-school demo... so far, my pipeline configuration looks like this:
resources:
- name: flight-school
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
- name: flight-school-version
type: semver
source:
driver: git
uri: https://github.com/nbering/flight-school
branch: master
file: version
jobs:
- name: test-app
plan:
- get: flight-school
trigger: true
- task: tests
file: flight-school/build.yml
- name: release-build
plan:
- aggregate:
- get: flight-school-version
trigger: true
- get: flight-school
passed: [test-app]
- task: release-build
file: flight-school/ci/release.yml
This produces a pipeline in the Web UI that looks like this:
The problem is that when I update the "release" file in the git repository, the semver resource, "flight-school-version" can check before the git resource "flight-school", causing the release build to be processed from the git version assigned to the previous check-in.
I'd like a way to work around this so that the release build appears as a separate task, but only triggers when the version is bumped.
Some things I've thought of so far
Create a separate git resource with a tag_filter set so that it only runs when a semver tag has been push to master
Pro: Jobs only run when tag is pushed
Con: Has the same disconnected-inheritance problem for tests as the semver-based example above
Add the conditional check for a semver tag (or change diff on a file) using the git history in the checkout as part of the build script
Pro: Will do basically what I want without too much wrestling with Concourse
Con: Can't see the difference in the UI without actually reading the build output
Con: Difficult to compose with other tasks and resource types to do something with the binary release
Manually trigger release build
Pro: Simple to set up
Con: Requires manual intervention.
Use the API to trigger a paused build step on completion of tests when a version change is detected
Con: Haven't seen any examples of others doing this, seems really complicated.
I haven't found a way to trigger a task when both the git resource and semver resource change.
I'm looking for either an answer to solve the concurrency problem in my above example, or an alternative pattern that would produce a similar release workflow.
Summary
Here's what I came up with for a solution, based on suggestions from the Concourse CI slack channel.
I added a parallel "release" track, which filters on tags resembling a semantic versioning versions. The two tracks share task configuration files and build scripts.
Tag Filtering
The git resource supports a tag_filter option. From the README:
tag_filter: Optional. If specified, the resource will only detect commits
that have a tag matching the expression that have been made against
the branch. Patterns are glob(7)
compatible (as in, bash compatible).
I used a simple glob pattern to match my semver tags (like v0.0.1):
v[0-9]*
At first I tried an "extglob" pattern, matching semantic versions exactly, like this:
v+([0-9]).+([0-9]).+([0-9])?(\-+([-A-Za-z0-9.]))?(\++([-A-Za-z0-9.]))
That didn't work, because the git resource isn't using the extglob shell option.
The end result is a resource that looks like this:
resource:
- name: flight-school-release
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
tag_filter: 'v[0-9]*'
Re-Using Task Definitions
The next challenge I faced was avoiding re-writing my test definition file for the release track. I would have to do this because all the file paths use the resource name, and I now have a resource for release, and development. My solution is to override the resource with an option on the get task.
jobs:
- name: test-app-release
plan:
- get: flight-school
resource: flight-school-release
trigger: true
- task: tests
file: flight-school/build.yml
Build.yml above is the standard example from the flight school tutorial.
Putting It All Together
My resulting pipeline looks like this:
My complete pipeline config looks like this:
resources:
- name: flight-school-master
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
- name: flight-school-release
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
tag_filter: 'v[0-9]*'
jobs:
- name: test-app-dev
plan:
- get: flight-school
resource: flight-school-master
trigger: true
- task: tests
file: flight-school/build.yml
- name: test-app-release
plan:
- get: flight-school
resource: flight-school-release
trigger: true
- task: tests
file: flight-school/build.yml
- name: build-release
plan:
- get: flight-school
resource: flight-school-release
trigger: true
passed: [test-app-release]
- task: release-build
file: flight-school/ci/release.yml
In my opinion you should manually click the release-build button, and let everything else be automated. I'm assuming you are manually bumping your version number, but it seems better to move that manual intervention to releasing.
What I would do is have put at the end of release-build that bumps your minor version. Something like:
- put: flight-school-version
params:
bump: minor
That way you will always be on the correct version, once you release 0.0.1, you are done with it forever, you can only go forward.
I am getting this message:
"GitHub" deployment has been skipped as environment variable has not matched ("appveyor_repo_tag" is "false", should be "true")
But, as can be seen in my Appveyor.yml:
https://github.com/GrokImageCompression/grok/blob/master/appveyor.yml
appveyor_repo_tag is actually set to true
remove skip_tags: true
add tag: $(APPVEYOR_REPO_TAG_NAME) in GitHub deployment setting (to prevent AppVeyor from creating a new tag, and endless build loop)
optionally add force_update: true (to update release details, not only files)
According to the Microsoft Documentation, in Azure Batch without the version specified the default version of an application will be deployed.
In my Azure Batch Account I have uploaded an application "MyApp" and set the default version, lets say version "1.0".
When I create a new Pool (in .NET) if I set the ApplicationPackageReferences omitting the version, i.e:
myCloudPool.ApplicationPackageReferences = new List<ApplicationPackageReference>
{
new ApplicationPackageReference
{
ApplicationId = "MyApp"
}
};
The nodes will get the status "Unusable".
If I do the same, but at task level, then the default application is deployed successfully to the node.
Why is that?
Thank you Olandese, I came across this specific case only in the case for default version at pool level and the fix is under its way, I will keep you posted when it will get released.
In the mean time there are few options or at pool level you can do so by using the version parameter.
Task level packages with default, which you are already mentioned above.
Use of the version parameter to pass the default version.
`
Sample:
new List< ApplicationPackageReference >
{
new ApplicationPackageReference(appID, version: appVersion),
},
`
Thanks for your patience, apologies for the inconvenience, will update you once the release is out.
Further addition: If you have faster changing default version
I would do it this way: (With appId as constant and the version as the dynamic version)
By doing this your code pretty much guarantees that node will go and grab the specified version mentioned if its there. Hope this helps.
`
new List<ApplicationPackageReference>
{
new ApplicationPackageReference(appID, version: appVersion),
},
I've got a Concourse job that uses the appearance of a file in an Amazon S3 bucket as a trigger to a suite of tests. Using this resource --> https://github.com/concourse/s3-resource . Problem is, the job is not firing when the file appears. When I trigger the job manually, it does see the file and start the test suite.
Yaml config looks like this:
- name: s3-trigger-file
type: s3
source:
bucket: my-bucket-name
regexp: qabot_request_(.*).json
access_key_id: {{s3-access-key-id}}
secret_access_key: {{s3-secret-access-key}}
jobs:
- name: my-job
public: true
plan:
- get: s3-trigger-file
trigger: true
When I click on the trigger itself in the Concourse UI, I see what looks like a running monitor:
As I said, the job isn't firing when the file appears, but a manual trigger does verify the S3 input is found.
How can I debug why the automatic trigger isn't firing? Also, how much latency is expected for the s3 resource to detect a new file has appeared?
Concourse 3.4. Thanks ~~
The capturing group in your regexp must refer to a semver compliant version.
See the documentation:
The version extracted from this pattern is used to version the resource. Semantic versions, or just numbers, are supported. Accordingly, full regular expressions are supported, to specify the capture groups.
Your capturing group is currently making the captured "version" quote2. You should probably delete the pipeline and regenerate it with a modified regex (e.g. qabot_request_quote(\d+).json)