수색…
비고
릴리스 트랙 게시는 a) publish-release 명령에 매개 변수로 .json 파일이 필요하고 b) 파일이 어떤 모양인지 이해하면 매우 간단합니다. 그것은 어디서나 문서화되지 않았기 때문에 확실히 시작하기 가장 큰 장애물입니다.
릴리스의 모든 패키지는 Atmosphere에 게시해야한다는 점을 명심하십시오. 응용 프로그램의 .meteor / versions 파일은 릴리스에 들어가야하는 모든 필요한 패키지와 버전을 찾는 데 특히 유용합니다.
그 후, 당신이 무엇을 지원하고 싶은지, 무엇을 포함시키고 싶은지를 알아내는 문제입니다. 여기 임상 발판이 현재 작업중인 부분 다이어 다이어그램이 있습니다. 당신에게 우리가 포함되는 것에 대한 의사 결정 과정을 어떻게 진행할 것인지에 대한 일반적인 생각을 제공해야합니다.
자세한 내용은 Meteor 포럼의 주제를 참조하십시오.
https://forums.meteor.com/t/custom-meteor-release/13736/6
기본 사용법
아이디어는 배포판 관리자가 다음과 같은 명령을 실행하려고한다는 것입니다.
meteor publish-release clinical.meteor.rc6.json
그러면 배포자의 사용자가 다음을 실행할 수 있습니다.
meteor run --release clinical:[email protected]
릴리스 매니페스트
릴리스 매니페스트는 Atmosphere 패키지 목록을 지정하고 해당 패키지 목록에 대해 약간의 메타 데이터를 제공하는 것이 가장 중요하다는 점에서 NPM package.json 파일과 유사합니다. 기본 형식은 다음과 같습니다.
{
"track":"distroname:METEOR",
"version":"x.y.z",
"recommended": false,
"tool": "distroname:[email protected]",
"description": "Description of the Distro",
"packages": {
"accounts-base":"1.2.0",
"accounts-password":"1.1.1",
...
}
}
유성 도구 사용자 정의
유성 툴이나 커맨드 라인을 확장해야한다면, 자신의 유성 툴 패키지를 생성하고 게시해야합니다. Ronen의 문서는이 과정에서 가장 좋습니다.
http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-mete-command-line-tool/1
유성 helloworld 명령을 사용하는 것은 쉽지만 그 후에는 명령을 테스트하기 위해 별도의 노드 응용 프로그램을 만드는 것이 더 쉽다고 느꼈습니다. StarryNight가 어떻게 생겼는지. 그것은 유성 툴의 버전에 넣으려고하기 전에 명령을위한 준비 지와 스크래치 패드의 무언가입니다.
.meteor / versions에서 릴리스 매니페스트 추출
StarryNight에는 응용 프로그램의 .meteor/versions 파일을 구문 분석하고이를 릴리스 매니페스트로 변환하는 작은 유틸리티가 들어 있습니다.
npm install -g starrynight
cd myapp
starrynight generate-release-json
StarryNight를 사용하지 않으려면 .meteor/versions 파일의 내용을 매니페스트 파일의 packages 필드에 복사하기 .meteor/versions 됩니다. JSON 구문으로 변환하고 콜론과 따옴표를 추가하십시오.
특정 릴리스에 대한 릴리스 매니페스트 표시
meteor show --ejson [email protected]
Checkout에서 출시 게시
meteor publish-release --from-checkout
릴리스의 각 패키지에 대한 최신 커밋 가져 오기
사용자 정의 릴리스 트랙을 빌드 할 때 /packages 디렉토리에있는 /packages 를 git 하위 모듈로 유지하는 것이 일반적입니다. 다음 명령을 사용하면 /packages 디렉토리의 하위 모듈에 대한 최신 커밋을 모두 동시에 가져올 수 있습니다.
git submodule foreach git pull origin master